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REMARKS 

This amendment is responsive to the Office Action dated April 8, 2008. Applicant has 
amended claim 32 and added claims 71-9L Claims 1-91 are pending. 

Claim Amendments to Correct Informalities 

Claim 32 has been amended to correct a preposition. 

Claim Rejection Under 3S U.S.C 3 102 

In the Office Action, the Examiner rejected claims 1-70 under 35 U.S.C, 102(e) as being 
anticipated by Bays (US 7,139,242). Applicant respectfully traverses the rejection. Bays fails to 
disclose each and every feature of the claimed invention, as required by 35 U.S.C. 102(e), and 
provides no teaching that would have suggested the desirability of modification to include such 
features. 

Prior to addressing the specific claims, the Applicant provides the following information 
to assist the Examiner in distinguishing between routing information and packet flow criteria, as 
recited in Applicant's claims* A packet flow, as the phrase is understood in the art, is an 
abstraction of a transmission of network packets from a particular source to a particular 
destination. As defined in the application specification and as used in the claims, flow 
specification data type may contain a variable number of attributes, or components, that 
correspond to the various criteria that are used to identify a particular packet flow.* Such 
attributes may include source information, destination information, port information, protocol, 
ICMP type, and packet length, among others, so as to precisely define a packet flow. 2 In this 
way, the criteria define a specific flow of packets, i.e., those packets that match that packet flow 
criteria, flowing from a source of those packets to the destination of those packets. 

In contrast, routing information carried by routing protocols contains a set of attributes 
that describe the current configuration of a network and generally corresponds to the information 
found in a routing table, or Routing Information Base (RIB), of a router. The RJB contains 
information needed by the router to properly route packets to their intended destinations; 

1 Application atffit [0008], [0039], 

-14- 



PAGE 1 6/23 * RCVD AT 7/812008 5:17:30 PM [Eastern Daylight Time] * SVR:U$PTO£FXRF-5/38 1 DNIS:2738300 * CSID:6517351 102 * DURATION (mm-ss):04-28 



87/88/2088 16:87 6517351182 



SHUMAKER & SIEFFRERT 



PAGE 17/23 



Application Number 10/732,291 

Amendment dated July 8, 2008 

Response to Office Action mailed April 8, 2008 

examples of routing information include network topology informati on describing routes through 
a network or Link state information describing the status of individual network links.. 

In general, Bays is directed toward systems and methods for optimizing routing choices 
by dynamically controlling and applying routing policies. 3 Routing policies are sets of rules that, 
for example, control path selection. That is, the router is directed to send packets in a particular 
direction based on the particular policy that is applied. In Bays, routing protocols are used in 
their conventional way to exchange network topology information. In contrast, the present 
application, describes techniques in which a routing protocol can additionally be used for 
distributing traffic flow criteria between routing devices, i.e., by using a routing protocol that has 
been extended so as to additionally carry traffic flow criteria for specifying individual packet 
flows . In this way, the extended routing protocol is being used in a manner beyond its 
conventional use, and the routing protocol communications between routers carry information 
that they normally would not cany. As explained in the specification, a router may then perform 
such applications as load balancing, rate limiting, togging, or filtering based on th e traffic flow 
criteria distributed via a routing protocol according to the invention . 

Claim J 

Bays fails to disclose a method comprising defining a flow specification data type for a 
routing protocol, wherein the flow specification data type allows a variable number of packet 
flow attributes to be specified, generating a message that encodes traffic flow criteria in 
accordance with the flow specification data type, and communicating the message to a routing 
device to direct the routing device to control network traffic based on the traffic flow criteria, as 
required by claim 1 . 

In support of the rejection, the Examiner first cited Bays at col. 4, lines 22-54, as 
disclosing defining a flow specification data type for a routing protocol, wherein the flow 
specification data type allows a variable number of packet flow attributes to be specified. This 
portion of Bays, however, describes defining, m odifying, and uploading routing policies, where a 
routing policy is a set of rules that determine the outcome of a routing decision. 4 Contrary to the 

3 See generally Bays at Summary. 

4 Bays at cot. 4, lines 27-30. 
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Examiner's assertions, the cited portion of Bays does not describe data types of any sort, let alone 
a data type that allows a variable number of packet flow attributes to be specified, as specifically 
recited in claim 1 . The cited portion of Bays does not mention packet flows, traffic flows, or 
similar terms. The cited portion only discusses policies. These policies are uploaded in a generic 
manner with no reference to protocols, messages, or data types. Therefore it cannot anticipate 
the limitation of a flow specification data type for encoding traffic flow criteria, as recited in 
claim I. These policies do not make use of a flow specification data type that allows a variable 
number of packet flow attributes to be specified, as recited in claim 1 . The Examiner has pointed 
to no evidence in Bays to even suggest that the policies allow criteria for specific packet flows to 
be defined, let alone in accordance with a defined data type that allows a variable number of 
packet flow attributes to be specified. 

Next, the Examiner cited Bays at col 20, line 45 - col. 2 1 , line 60, and stated that this 
portion of the reference anticipates generating a message that encodes traffic flow criteria in 
accordance with the flow specification data type. As discussed above, Bays does not reference or 
disclose anything resembling a flow specification data type and therefore cannot anticipate 
generating a message in accordance with the same. In addition, while this portion of the 
reference describes generating messages, the messages described carry no data that anticipates 
the recited traffic flow criteria of claim 1 . The messages generated in Bays are extremely simple 
IP packets with variable time to live field values 5 that a routing control device uses to map the 
network topology and its characteristics 6 * They certainly do not encode traffic flow criteria; nor 
do they do so in accordance with a defined flow specification data type. The Examiner has 
pointed to no evidence in Bays that the routing protocol messages are used to convey anything 
but routing information, let alone to additionally encode traffic flow criteria in accordance with 
the flow specification data type, wherein that flow specification data type allows a variable 
number of packet flow attributes to be specified, as specifically recited in claim L 

Finally, the Examiner stated that Bays at col. 4, line 55 - col. 5, line 26 discloses 
communicating the message to a routing device to direct the routing device to control network 
traffic based on the traffic flow criteria, as further recited by claim 1 . The process discussed in 

5 Bays at col. 21, lines 4-6. 

6 Id at col. 20, lines 46-47. 
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Bays is routing based op a routing policy configuration: that fact remains true for this portion of 
the reference. In contrast, this element of claim 1 requires that the routing device control 
network traffic based on the traffic flow criteria that it received in a message. Bays has no 
concept of controlling network traffic using traffic flow criteria that is communicated within a 
message, let alone where that traffic flow criteria conforms to a flow specification data type that 
allows a variable number of packet flow attributes to be specified, as required by claim 1 . In 
Bays, the decision making described is based on information about the routes themselves 7 (not 
packet flows), in addition to the policy configurations 8 . It therefore cannot anticipate a limitation 
that describes controlling network traffic based on traffic flow criteria that is communicated 
within a message, where that traffic flow criteria conforms to a flow specification data type that 
allows a variable number of packet flow attributes to be specified, as required by claim 1 . 

In order to support an anticipation rejection under 35 U.S>C 102(e), it is well established 
that a prior art reference must disclose each and every element of a claim. This well known rule 
of law is commonly referred to as the "all-elements rule." 9 If a prior art reference fails to 
disclose any element of a claim, then rejection under 35 U.S.C. 102(e) is improper. 10 

For at least the foregoing reasons, Bays does not disclose each and every element of claim 
1 . Therefore, it is not anticipated by and is patentable over Bays. 

Claim 2-15 

Claims dependent upon claim 1 incorporate all of its limitations, and therefore are 
patentable for the reasons expressed above. In addition, at least the following supplementary 
arguments apply. » 

Claim 2 recites defining the flow specification data type as information associated with a 
route advertised by the message. Thus, according to claim 2, in addition to advertising a route, 
the generated message includes the flow specification data type as information associated with 

7 Id. at col. 7, tine 65 - coL 8, line 4. 
■/<£ 

9 See Hybritechlnc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 231 USPQ 81 (CAFC 1986) ("it is axiomatic 
that for prior an to anticipate under 102 it has to meet every element of the claimed invention"). 

10 Id. See also Lewmar Marine. Inc. v. Barieni, Inc. 827 F-2d 744, 3 USPQ2d 1766 (CAFC 1987); In re Bona\ 910 
F.2d 831, 15 USPQ2d 1566 (CAFC 1990); C.R. Bara\ Inc. v. MP Systems. Inc., 157 F.3d 1340, 48 USPQ2d 1225 
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that particular advertised route. In this way, a route can be associated with its own flow 
specification so as to provide for fine-grain control over the packet flows. These features are also 
not disclosed in Bays, col. 16, line 63 - col 17, line 1 1, as cited by the Examiner. 11 Indeed, 
routing protocols have mechanisms for advertising available routes to particular destinations. 
The portion of Bays cited by the Examiner merely describes modifying* with BGP techniques, 
the characteristics of an advertised route according to a configuration policy. Nevertheless, in 
Bays, BGP is still used only to advertise router and not to incorporate any packet flow 
information within the routing message, and certainly without associating additional information 
of the flow specification data type with a specific advertised route, as required by claim 2. 

In addition, claim 3 requires defining a flow specification data type as network layer 
reachability information (NLRI) that is associated with a route advertised by the message. Thus, 
it is a particularized form of claim 2 in that NLRI for a specific router is used to carry this 
additional variable number of packet flow attributes for encoding the packet flow criteria. Again, 
Bays does not describe routing message that carry any information other than the network 
topology information and other routing information conventionally carried by routing protocols. 
It certainly does not anticipate these features of claim 2. 

Regarding claim 4, the "mask length" referred to in Bays* coL 17, line 12 - col. 18, line 
24 12 is unrelated to a variable number of attributes that may be contained in a data type. Subnet 
masks are tools for simplifying routing and are used in conjunction with network addresses so as 
to mask portions of the network address. The length of the mask is proportional to the size of the 
subnet, and has no relation to data types, let alone a flow specification data type for defining a 
packet flow. 

Claims 5-7 describe defining various subcomponents of the flow specification type, 
which is not anticipated by the descriptions of alterations to routing policies in the reference as 
cited by the Examiner. 13 



(CAFC 1998); Oney v. Rattiff, 182 F.3d 893, 51 USPQ2d 1697 (CAFC 1999); Apple Computer, Inc. v. Articulate 
System. Inc., 234 F.3d 14, 57 USPQ2d 1057 (CAFC 2000), 
"Office Action at 2. 

12 Id at 3. 

13 j J 
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Claim 8 is a particularized form of claim 1 and allowable for the reasons set forth in 
defense of that claim. Bays, col. 17, line 12 - col. 18, line 24 as cited by the Examiner against 
claim 9 M does not disclose redefining or even modifying existing data types. As described above, 
that portion discusses the relationship of the network mask to the size of the subnet being 
analyzed. 

Claims 10 and 1 1-13 include the limitation of an application-specific data type and an 
application-specific identifier, respectively* First, defining the flow specification data type as an 
application-specific data type in accordance with the routing protocol is not disclosed in Bays, 
col. 1 7, line 12 - col. 18, line 24, as argued by the Examiner. 15 As described above, that portion 
discusses the relationship of the network mask to the size of the subnet being analyzed. It does 
not disclose, discuss, nor suggest redefining nor even modifying existing data types. Second, 
according to the specification, the presence of an application-specific identifier indicates that a 
routing communication includes encoded traffic criteria consistent with the principles of the 
invention, and any advertised routes within the routing communication should be installed within 
a separate routing information base. 16 In the Office Action, the Examiner stated that this feature 
is anticipated by Bays, col. 7, lines 31-64. 17 The Applicant has had difficulty reconstructing the 
Examiner's argument. The only similarity between this portion of the reference and claims 1 1-13 
is the shared presence of the term "identifier." This fact does not avail the rejection, however. 
Assigning an application-specific identifier, according the application, puts recipients of routing 
communications on notice that the routing communication pertains to the flow specification data 
type in some way. 18 As used in the reference, the "identifier" is a "unique identifier" 19 that refers 
to a specific peer on the routing system* 5 . These two uses of the term are incongruous; the 
portion of the reference cited by the Examiner, therefore, does not anticipate these claims. 



]A ld at 4. 
i5 rd 

16 Application at [0037]. 

17 Office Action at 4. 
'» Id 

19 Bays at col 7, line 53. 

20 Id at col. 7, lines 53^54. 
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Finally, claims 14-15 include the limitation of using the traffic flow criteria to specify an 
appropriate action that is performed on the network packet. Because Bays has no concept of 
traffic flow criteria, it cannot anticipate these claims. 

For at least the foregoing reasons, claims 2-1 5 are patentable over Bays. 

Claims 16-70 

Claim 16-70 include additional method claims as well as apparatus claims that 
correspond to claims 1-15. The arguments marshaled in favor of the patentability of claims 1-15 
apply in similar measure to these additional claims. 

Summary 

Bays fails to disclose each and every limitation set forth in claims 1-70. For at least the 
reasons offered above, the Examiner has failed to establish a prima facie case for anticipation of 
Applicant's claims 1-70 under 35 U.3.C. 102(e). Withdrawal of this rejection is requested. 

New Claims: 

Applicant has added claims 71-91 to the pending application. The applied references fail 
to disclose or suggest the inventions defined by Applicants new claims, and provide no teaching 
that would have suggested the desirability of modification to arrive at the claimed inventions. 

As one example, claims 71-73, which are dependent upon claim 1, contain the limitation 
of encoding routing information in accordance with a routing protocol. Thus* dependent claim 
71 makes clear that the generated message recited in claim 1 encodes both: (1) traffic flow 
criteria in accordance with the flow specification data type, and (2) routing information in 
accordance with the routing protocol. This makes plainly clear that the recited message is 
different from a conventional routing message that merely conveys routing information. 

No new matter has been added by the new claims. 
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CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1 778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: By: 
Mv 8. 2008 

SHUMAKER & SIEFFERT, PA. Name: Kent J. Sieffert 

1 625 Radio Drive, Suite 300 Reg. No.: 41,31 2 

Woodbury, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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